Field of the Disclosure
The technology of the disclosure relates generally to Session Traversal Utilities for Network Address Translation (STUN) methods and protocols for enabling Network Address Translation (NAT) traversal.
Technical Background
The advent of Web Real-Time Communications (WebRTC), an ongoing effort to develop industry standards for integrating real-time communications functionality into web clients such as web browsers, has resulted in a proliferation of web clients capable of direct interaction with other web clients. The real-time communications functionality enabled by WebRTC is accessible by web developers via standard markup tags, such as those provided by version 5 of the Hyper Text Markup Language (HTML5), and client-side scripting Application Programming Interfaces (APIs) such as JavaScript APIs. More information regarding WebRTC may be found in “WebRTC: APIs and RTCWEB Protocols of the HTML5 Real-Time Web,” by Alan B. Johnston and Daniel C. Burnett, 2nd Edition (2013 Digital Codex LLC), which is incorporated in its entirety herein by reference.
Direct interaction among WebRTC-enabled web clients or other real-time communications web clients may be hampered by network traversal issues caused by the presence of Network Address Translation (NAT) devices, such as network traffic routing devices, in the network path between the web clients. A NAT device maps the Internet Protocol (IP) addresses of multiple web clients on a local network to a single publicly exposed IP address. As packets of network traffic pass from each web client to the Internet, the NAT device translates the source address of each packet from the web client's IP address on the local network to the public IP address. When a reply returns to the public IP address from the Internet, the NAT device uses connection tracking data to determine the local network address to which the reply is to be forwarded. Because a web client on the local network may not be aware of the public IP address provided by the NAT device, the web client may be unable to establish a direct connection with another web client outside the local network.
To address these network traversal issues, a network protocol known as Session Traversal Utilities for Network Address Translation (STUN) (defined by the Request for Comments (RFC) 5389, available online at http://www.ietf.org/rfc/rfc5389.txt) has been developed. A WebRTC-enabled web client may use a STUN server to determine the public IP address allocated to it by a NAT device, and may provide the public IP address to a remote endpoint in order to establish real-time communications. An extension to STUN known as Traversal Using Relays around Network Address Translation (TURN) (defined by RFC 5766, available online at http://www.ietf.org/rfc/rfc5766.txt) provides additional network traversal capabilities by relaying network traffic through a TURN server on the Internet.
STUN provides both short-term and long-term credential mechanisms that a STUN server and client may use to authenticate STUN messages. Both mechanisms rely on the STUN server and client exchanging a credential (e.g., a username and password) using some other protocol prior to authenticating a STUN message. However, STUN includes no mechanism for providing STUN services based on an origin of a web application (e.g., a “web origin” as defined by RFC 6454, available online at http://www.ietf.org/rfc/rfc6454.txt) that generates a STUN message. For example, a STUN server may be unable to determine whether a web application that is attempting to send a STUN message to the STUN server originated from a source that is authorized to access the STUN server. This may pose challenges to entities such as enterprises that wish to permit access to enterprise STUN servers only by enterprise web applications or other web applications originating from authorized sources.